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Intellectual Property Rights 



IPRs essential or potentially essential to the present document may have been declared to ETSI. The information 
pertaining to these essential IPRs, if any, is publicly available for ETSI members and non-members, and can be found 
in SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI in respect 
of ETSI standards", which is available free of charge from the ETSI Secretariat. Latest updates are available on the 
ETSI Web server (http://www.etsi.fr/ipr or http://www.etsi.org/ipr). 

Pursuant to the ETSI IPR Policy, no investigation, including IPR searches, has been carried out by ETSI. No guarantee 
can be given as to the existence of other IPRs not referenced in SR 000 314 (or the updates on the ETSI Web server) 
which are, or may be, or may become, essential to the present document. 



Foreword 



This ETSI Technical Specification (TS) has been produced by the Special Mobile Group (SMG) of the European 
Telecommunications Standards Institute (ETSI). 

This TS describes the Subnetwork Dependent Convergence Protocol (SNDCP) for the General Packet Radio Service 
(GPRS) within the digital cellular telecommunications system. 

The contents of this TS are subject to continuing work within SMG and may change following formal SMG approval. 
Should SMG modify the contents of this TS it will then be released by ETSI with an identifying change of release date 
and an increase in version number as follows: 

Version 6.x.y 

where: 

6 GSM Phase 2+ Release 1997 

X the second digit is incremented for all other types of changes, i.e. technical enhancements, corrections, 
updates, etc. 

y the third digit is incremented when editorial only changes have been incorporated in the specification. 
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1 Scope 



This ETSI TS provides the description of the Subnetwork Dependent Convergence Protocol (SNDCP) for the General 
Packet Radio Service (GPRS). 

The user of the services provided by SNDCP is a packet data protocol (PDP) at the mobile Station (MS) or the Relay at 
the Serving GPRS Support Node (SGSN). Additionally, a control entity, e.g., AT command interpreter, may be an 
SNDCP user. SNDCP uses the services provided by the Logical Link Control (LLC) layer [4] and the Session 
Management (SM) sub-layer [2] . 

The main functions of SNDCP are: 

Multiplexing of several PDPs. 

Compression/decompression of user data. 

- Compression/decompression of protocol control information. 

Segmentation of a network protocol data unit (N-PDU) into Logical Link Control Protocol Data Units (LL- 
PDUs) and re-assembly of LL-PDUs into a N-PDU. 

GSM 04.65 is applicable to GPRS MS and SGSN. 



Normative references 



References may be made to: 

a) specific versions of publications (identified by date of publication, edition number, version number, etc.), in 
which case, subsequent revisions to the referenced document do not apply; or 

b) all versions up to and including the identified version (identified by "up to and including" before the version 
identity); or 

c) all versions subsequent to and including the identified version (identified by "onwards" following the version 
identity); or 

d) publications without mention of a specific version, in which case the latest version applies. 

A non-specific reference to an ETS shall also be taken to refer to later versions published as an EN with the same 
number. 

[1] GSM 0L04: "Digital cellular telecommunications system (Phase 2+); Abbreviations and 

acronyms". 

[2] GSM 02.60: "Digital cellular telecommunication system; General Packet Radio Service (GPRS); 

Service Description, Stage 1". 

[3] GSM 03.60: "Digital cellular telecommunication system; General Packet Radio Service (GPRS); 

Service Description, Stage 2". 

[4] GSM 04.07: "Digital cellular telecommunications system (Phase 2+); Mobile radio interface 

signalling layer 3; General aspects". 

[5] GSM 04.08: "Digital cellular telecommunications system (Phase 2+), Mobile radio interface layer 

3 specification". 

[6] GSM 04.64: "Digital cellular telecommunication system; General Packet Radio Service (GPRS); 

Mobile Station - Serving GPRS Support Node (MS-SGSN) Logical Link Control (LLC) Layer 
Specification". 

[7] GSM 09.60: "Digital cellular telecommunications system (Phase 2+), General Packet Radio 

Service (GPRS); GPRS Tunnelling Protocol (GTP) across the Gn and Gp Interface". 
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[8] 



[9] 



ITU-T, Recommendation V.42 bis: "Data compression procedures for data circuit- terminating 
equipment (DCE) using error correcting procedures". 

RFC- 1 144, V. Jacobson: "Compressing TCP/IP Headers for Low-Speed Serial Links". 



3.1 



Definitions and Abbreviations 



Definitions 



In addition to the definitions in 02.60 [2] the following definitions apply: 



N201 

N201-I 

N201-U 

N-PDU number 
NSAPI 

Protection mode 



SAPI 

Segment offset 
SNDCP entity 



LLC layer parameter (see GSM 04.64 for clarity). Defines maximum number of octets in 
the information field of LL-PDU. Separate values are applicable for I (see N201-I), U and 
UI (see N201-U) LL-PDUs. 

LLC layer parameter (see GSM 04.64 for clarity). Defines maximum number of octets 
available to a SN-DATA PDU for a specific SAPI. 

LLC layer parameter (see GSM 04.64 for clarity). Defines maximum number of octets 
available to a SN-UNITDATA PDU for a specific SAPI. 

A sequence number assigned to N-PDUs per NSAPI in unacknowledged mode. 

For each SN-PDU the NSAPI is an index to the PDP context of the PDP that is using the 
services provided by the SNDCP layer. 

Identifies the transfer mode for SN-UNITDATA transfer. In the protected mode, the lower 
layers shall discard the erroneous data when an error in the check sequence of the received 
user data is noticed. The erroneous data is not delivered to SNDCP layer at the receiving 
entity. In the unprotected mode, the correctness of the received information is not 
checked. The received information is transferred transparently to the peer SNDCP layer 
and to the user of the peer SNDCP entity. 

SAPI identifies the Service Access Point (with which a QoS profile is associated) that the 
SN-PDU is using at the LLC layer. 

Indicates the offset from the beginning of the N-PDU. 

The SNDCP entity handles the service functions provided by the SNDCP layer. The 
SNDCP entity is temporary logical link identity specific. 



SNDCP management entity The SNDCP management entity handles communication with SM sub-layer and controls 

the operation of the SNDCP entity. 



SNDCP user 



Protocol entity that is using the services provided by the SNDCP layer. PDP entities and 
control entities, e.g., AT command interpreter, are the SNDCP users at the MS. Relay 
entity is the SNDCP user at the SGSN. 



Refer to GSM 02.60 [2] for further GPRS definitions. 



3.2 



Abbreviations 



In addition to abbreviations in 01.04 [1] and 02.60 [2] the following abbreviations apply: 

DCOMP Identifier of the user data compression algorithm used for the N-PDU 

E Extension bit 

IP Internet Protocol 

GMM GPRS Mobility Management 

LLC Logical Link Control 

M More bit used to indicate the last segment of N-PDU 
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N-PDU Network Protocol Data Unit 

NSAPI Network Layer Service Access Point Identifier 

PCOMP Identifier of the protocol control information compression algorithm used for the N-PDU 

PDP Packet Data Protocol e.g., IP or X.25 

PDU Protocol Data Unit 

PTP Point to Point 

QoS Quality of Service 

SAPI Service Access Point Identifier 

SDU Service Data Unit 

SGSN Serving GPRS Support Node 

SM Session Management 

SNDCP Subnetwork Dependent Convergence Protocol 

SNSM SNDCP-SM 

TCP Transmission Control Protocol 

TLLI Temporary Logical Link Identifier 

X Spare bit. 



General 



This document describes the functionality of the GPRS SNDCP. The overall GPRS logical architecture is defined in 
GSM 03.60 [3]. Location of the SNDCP in GPRS protocol stack can be seen in Figure I. 
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Figure 1 : GPRS protocol stack 

Network layer protocols are intended to be capable of operating over services derived from a wide variety of 
subnetworks and data links. GPRS supports several network layer protocols providing protocol transparency for the 
users of the service. Introduction of new network layer protocols to be transferred over GPRS shall be possible without 
any changes to GPRS. Therefore, all functions related to transfer of Network layer Protocol Data Units (N-PDUs) shall 
be carried out in a transparent way by the GPRS network entities. This is one of the requirements for GPRS SNDCP. 

Another requirement for the SNDCP is to provide functions that help to improve channel efficiency. This requirement is 
fulfilled by means of compression techniques. 

The set of protocol entities above SNDCP consists of commonly used network protocols. They all use the same SNDCP 
entity, which then performs multiplexing of data coming from different sources to be sent using the service provided by 
the LLC layer (figure 2). The Network Service Access Point Identifier (NSAPI) is an index to the PDP context (see 
GSM 03.60 [3]) of the PDP that is using the services provided by SNDCP. One PDP may have several PDP contexts 
and NSAPIs. However, it is possible that each allocated NSAPI is used by separate PDP. Each active NSAPI shall use 
the services provided by the Service Access Point Identifier (SAPI) in the LLC layer. Several NSAPIs may be 
associated with the same SAPI. 
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Since the adaptation of different network layer protocols to SNDCP is implementation dependent, it is not defined in 
this document. 




Figure 2: Example for multiplexing of different protocols 



Service Primitives and Functions 



5.1 Service Primitives 

This subclause explains the service primitives used for communication between the SNDCP layer and other layers. See 
also GSM 04.07 [4] to get an overall picture of the service primitives. Figure 3 illustrates the service access points 
through which the primitives are carried out. 
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Figure 3: Service Access Points provided and used by SNDCP 

5.1 .1 SNDCP Service Primitives 

The primitives provided by the SNDCP layer are Hsted in Table 1 . 

Table 1 : SNDCP layer service primitives 



Generic 
Name 


Type 


Parameters 


Request 


Indication 


Response 


Confirm 


SNDCP User (PDF or the SGSN Relay) <— > SNDCP 


SN-DATA 


X 


X 


- 


- 


N-PDU, NSAPI 


SN-UNITDATA 


X 


X 


' 


' 


N-PDU, NSAPI, 
protection mode 


SN-XID 


X 


X 


' 


' 


Requested SNDCP XID 
parameters 


SN-XID 


" 


" 


X 


X 


Negotiated SNDCP XID 
parameters 



5.1.1.1 



SN-DATA.request 



Request used by the SNDCP user for acknowledged transmission of N-PDU. The successful transmission of SN-PDU 
shall be confirmed by the LLC layer. The SN-DATA.request primitive conveys NSAPI to identify the PDP using the 
service. 
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5.1.1.2 SN-DATA.indication 

Indication used by the SNDCP entity to deliver the received N-PDU to the SNDCP user. Successful reception has been 
acknowledged by the LLC layer. 

5.1.1.3 SN-UNITDATA.request 

Request used by the SNDCP user for unacknowledged transmission of N-PDU. The SN-UNITDATA.request primitive 
conveys NSAPI to identify the PDP using the service and protection mode to identify the requested transmission mode. 

5.1.1.4 SN-UNITDATA.indication 

Indication used by the SNDCP entity to dehver the received N-PDU to the SNDCP user. 

5.1.1.5 SN-XID.request 

Request used by the SNDCP user at the initiating entity to deliver the list of requested XID parameters to the peer entity. 

5.1.1.6 SN-XID. indication 

Indication used by the SNDCP entity to deliver the list of requested XID parameters to the SNDCP user. 

5.1.1.7 SN-XID. response 

Response used by the SNDCP user to deliver the list of negotiated XID parameters to the peer entity. 

5.1.1.8 SN-XID.confirm 

Confirm used by the SNDCP entity to deliver the list of negotiated XID parameters to the SNDCP user. 

5.1 .2 Service Primitives Used by SNDCP Layer 

The SNDCP layer uses the service primitives provided by the SM sublayer and the LLC layer (see Table 2). SM is 
specified in GSM 04.08 [5] and LLC in GSM 04.64 [6]. 
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Table 2: Service primitives used by the SNDCP entity 



Generic 
Name 


Type 


Parameters 


Request 


Indication 


Response 


Confirm 


SNDCP <— > LLC 


LL-ESTABLISH 


X 


- 


- 


- 


TLLI, XID Requested 


LL-ESTABLISH 


" 


X 


" 


" 


TLLI, XID Requested, 

N201-I,N201-U 


LL-ESTABLISH 


- 


- 


X 


- 


TLLI, XID Negotiated 


LL-ESTABLISH 








X 


TLLI, XID Negotiated, 
N201-I, N201-U 


LL-RELEASE 


X 


X 


- 


X 


TLLI 


LL-XID 


X 


- 


- 


- 


TLLI, XID Requested 


LL-XID 


" 


X 


" 


" 


TLLI, XID Requested, 

N201-I, N201-U 


LL-XID 


- 


- 


X 


- 


TLLI, XID Negotiated 


LL-XID 


" 


" 


" 


X 


TLLI, XID Negotiated, 
N201-I, N201-U 


LL-DATA 


X 








TLLI, SN-PDU, 
Reference 


LL-DATA 


- 


X 


- 


- 


TLLI, SN-PDU 


LL-DATA 


- 


- 


- 


X 


TLLI, Reference 


LL-DATASENT 


- 


X 


- 


- 


TLLI, Reference, V(S) 


LL-UNITDATA 


X 


' 


' 


' 


TLLI, SN-PDU, 
Protection mode. Cipher 


LL-UNITDATA 


- 


X 


- 


- 


TLLI, SN-PDU 


SNDCP <— > SM 


SNSM-ACTIVATE 




X 






TLLI, NSAPI, QoS 
profile, Ack/Unack 
indicator, SAPI 


SNSM-ACTIVATE 


- 


- 


X 




TLLI, NSAPI 


SNSM-DEACTIVATE 


" 


X 


" 


" 


TLLI, NSAPI(s), LLC 
release indicator 


SNSM-DEACTIVATE 


- 


- 


X 


- 


TLLI, NSAPI 


SNSM-MODIFY 


" 


X 


" 


" 


TLLI, NSAPI, QoS 
profile, SAPI 


SNSM-MODIFY 


- 


- 


X 


- 


TLLI, NSAPI 


SNSM-WINDOW 


- 


X 


- 


- 


TLLI, NSAPIsH-V(R)s 
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5.1.2.1 LL-ESTABLISH.request 

Request used by the SNDCP layer to establish acknowledged peer-to-peer operation in the LLC layer. The request may 
be used by the SNDCP layer to deliver the requested SNDCP XID parameters to the LLC layer. XID Requested is used 
to negotiate SNDCP parameters. 

5.1.2.2 LL-ESTABLISH. indication 

Indication used by the LLC layer to inform SNDCP layer about establishment of acknowledged peer-to-peer operation 
in the LLC layer. XID Requested is used to negotiate SNDCP parameters. In case the received LLC frameincludes the 
requested SNDCP XID parameters, the indication shall be used by the LLC layer to deliver the requested SNDCP XID 
parameters to the SNDCP layer. In case of a link re-establishment, all buffered N-PDUs (i.e. the one whose complete 
reception has not been acknowledged and the one which has not bee transmitted yet) are to be transmitted starting with 
the oldest N-PDU when the link is re-established. Also any compression entities associated to this LLC link at the 
SNDCP layer are reset. 

5.1.2.3 LL-ESTABLISH. response 

Response used by the SNDCP layer after reception of the LL-ESTABLISH. indication. XID Negotiated is used to 
negotiate SNDCP parameters. In case the LL-ESTABLISH. indication included the requested SNDCP XID parameters, 
the response shall be used by the SNDCP layer to deliver the negotiated SNDCP XID parameters to the LLC layer. 

5.1.2.4 LL-ESTABLISH.confirm 

Confirm used by the LLC layer to inform SNDCP layer about successful initiation of acknowledged peer-to-peer 
operation in the LLC layer. XID Negotiated is used to negotiate SNDCP parameters. In case the LLC frameincludes the 
negotiated SNDCP XID parameters, the confirm shall be used by the LLC layer to deliver the negotiated SNDCP XID 
parameters to the SNDCP layer. In case of a link re-establishment, all buffered N-PDUs (i.e. the one whose complete 
reception has not been acknowledged and the one which has not bee transmitted yet) are to be transmitted starting with 
the oldest N-PDU when the link is re-established. Also any compression entities associated to this LLC link at the 
SNDCP layer are reset. 

5.1.2.5 LL-RELEASE.request 

Request used by the SNDCP layer to release acknowledged peer-to-peer operation in the LLC layer. 

5.1.2.6 LL-RELEASE.indlcation 

Indication used by the LLC layer to inform SNDCP layer about termination of acknowledged peer-to-peer operation in 
the LLC layer. The primitive is triggered by the reception of disconnect mode (DISC) LL-PDU in the LLC layer. 

If the SNDCP entity receives LL-RELEASE.indication while there are still N-PDUs to be transmitted on that logical 
link, the SNDCP entity shall establish a new logical link using the LL-ESTABLISH.request. On receipt of LL- 
RELEASE.indication, compressed N-PDUs queuing to be forwarded to LLC-layer are deleted from the SNDCP layer. 
Also any compression entities associated to this LLC link are reset. 

5.1.2.7 LL-RELEASE.confirm 

Confirm used by the LLC layer to inform SNDCP layer about termination of acknowledged peer-to-peer operation in the 
LLC layer. On receipt of LL-RELEASE.confirm, compressed N-PDUs queuing to be forwarded to LLC-layer are 
deleted from the SNDCP layer. Also any compression entities associated to this LLC link at the SNDCP are reset. 

5.1.2.8 LL-XID. request 

Request used by the SNDCP layer to deliver the requested SNDCP XID parameters to the LLC layer. 

5.1.2.9 LL-XID. indication 

Indication used by the LLC layer to deliver the requested SNDCP XID parameters to the SNDCP layer. 
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5.1.2.10 LL-XID. response 

Response used by the SNDCP layer to deliver the negotiated SNDCP XID parameters to the LLC layer. 

5.1.2.11 LL-XID.confirm 

Confirm used by the LLC layer to deliver the negotiated SNDCP XID parameters to the SNDCP layer. 

5.1.2.12 LL-DATA.request 

Request used by the SNDCP layer for acknowledged transmission of a SN-PDU. The SNDCP entity shall associate a 
reference parameter for each LL-DATA.request. 

The logical link shall be established using the LL-ESTABLISH primitives, before the LL-DATA.request may be used. 

5.1.2.13 LL-DATA.indication 

Indication used by the LLC layer to deliver the successfully received SN-PDU to the SNDCP layer. 

5.1.2.14 LL-DATA.confirm 

Confirm used by the LLC layer to inform SNDCP layer about successful transmission of SN-PDU. The primitive 
includes a reference parameter from which the SNDCP entity shall identify the LL-DATA.request this confirmation was 
associated with. All buffered N-PDUs whose complete reception is confirmed are deleted. 

5.1.2.15 LL-DATASENT.indication 

The LL-DATASENT.indication primitive is used by the LLC layer in acknowledged mode in the SGSN to inform 
SNDCP of which LLC send sequence number that was assigned to an LLC PDU. SNDCP uses this information to 
associate the LLC send sequence number with the corresponding N-PDU. 

5.1.2.16 LL-UNITDATA.request 

Request used by the SNDCP layer for unacknowledged transmission of a SN-PDU. Unconfirmed transmission shall be 
used by the LLC layer. 

Acknowledged peer-to-peer mode does not need to be established before unacknowledged transmission is allowed. 

5.1.2.17 LL-UNITDATA.indication 

Indication used by the LLC layer to deliver the received SN-PDU to the SNDCP layer. 

There is no need for logical link on the acknowledged-peer-to-peer mode for unacknowledged transmission of SN-PDU. 

5.1 .2.1 8 SNSM-ACTIVATE.indication 

Indication used by the SM entity to establish or reuse the acknowledged peer-to-peer LLC operation for a specific 
NSAPI during the ongoing PDP Context Activation procedure. This primitive is used by the SM entity to inform the 
SNDCP entity about the NSAPI and the related S API that has been allocated for the use of the SNDCP entity. 

Upon reception of the SNSM-ACTIVATE.indication from the SM sublayer, the SNDCP entity of the MS shall use the 
LL-ESTABLISH. request primitive to establish the acknowledged peer-to-peer LLC operation, as requested for a 
specific NSAPI. If an appropriate acknowledged peer-to-peer operation (including the requested XID parameters) is 
already up and running, there is no need for re-establishment of the link. If an acknowledged peer-to-peer operation is 
already up and running but the XID parameters are not correct, the SNDCP entity shall issue LL-XID-request to 
negotiate the requested XID parameters. 
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5.1.2.19 SNSM-ACTIVATE.response 

Response used by the SNDCP layer to inform SM entity that the acknowledged peer-to-peer operation mode is up and 
running with the requested XID parameters. 

5.1 .2.20 SNSM-DEACTIVATE.indication 

Indication used by the SM entity during the PDP Context Deactivation to trigger termination of the acknowledged peer- 
to-peer LLC operation for a specific NSAPIs. This primitive is used by the SM entity to inform the SNDCP entity about 
the NSAPI that has been deallocated and cannot be used by the SNDCP entity anymore. All buffered N-PDUs 
corresponding to this NSAPI are deleted. 

When receiving the SNSM-DEACTIVATE.indication, the SNDCP entity shall check if there are other NSAPIs using 
the same logical link. If the logical link is not used by other NSAPIs, the SNDCP entity shall use LL-RELEASE.request 
to terminate the acknowledged peer-to-peer LLC operation. The termination shall be started by the entity (MS or SGSN) 
where the PDP Context Deactivation was started. 

5.1 .2.21 SNSM-DEACTIVATE. response 

Response used by the SNDCP layer to inform SM entity about successfully deactivated PDP Context and logical links 
that have not been used by other NSAPIs. The primitive is triggered by the LL-RELEASE.indication and LL- 
RELEASE.confirm primitives after the SNSM-RELEASE.indication primitive. 

5.1.2.22 SNSM-MODIFY.indication 

Indication used by the SM entity to trigger change of the QoS for one NSAPI and indication of the S API to be used. 
The primitive triggers release of a logical link (using the LL-RELEASE.request sent by the SNDCP entity of the SGSN) 
that after the modification of the QoS profile values is not used by any NSAPIs. If no logical link exists for the 
requested QoS profile, the SNDCP entity of the SGSN shall establish a new logical link with the requested XID 
parameters using the LL-ESTABLISH.request primitive. 

5.1.2.23 SNSM-MODIFY.response 

Response used by the SNDCP entity to inform SM entity that the change of the QoS profile values has been carried out 
for the NSAPIs. 

5.1.2.24 SNSM-WINDOW.indication 

This primitive is only included in the SGSN and is used in the case of Inter SGSN RA Update. The primitive is used in 
the new SGSN by the SM entity to inform the SNDCP entity about the LLC PDU sequence number that has been 
correctly received by the MS. This is indicated by the V(R) value received from the MS during the Inter SGSN RA 
Update procedure. The SNDCP entity of the SGSN uses this information to delete all buffered N-PDUs whose complete 
reception is confirmed. 

5.2 Service Functions 

SNDCP shall perform the following functions (see figure 3): 

Mapping of SN-DATA primitives onto LL-DATA primitives. 
- Mapping of SN-UNITDATA primitives onto LL-UNITDATA primitives. 

Multiplexing of N-PDUs from one or several network layer entities onto the appropriate LLC connection. 
N-PDU buffering at SNDCP for acknowledged service. 
Management of delivery sequence for each NSAPI, independently. 
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Compression of redundant protocol control information (e.g., TCP/IP header) at the transmitting entity and 
decompression at the receiving entity. The compression method is specific to the particular network layer or 
transport layer protocols in use. 

Compression of redundant user data at the transmitting entity and decompression at the receiving entity. Data 
compression is performed independently for each SAPI, and may be performed independently for each PDP 
context. Compression parameters are negotiated between the MS and the SGSN. 

Segmentation and reassembly. The output of the compressor functions is segmented to the maximum length of 
LL-PDU. These procedures are independent of the particular network layer protocol in use. 

Negotiation of the XID parameters between peer SNDCP entities using XID exchange. 
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Figure 4 shows the transmission flow through SNDCP layer. The order of functions is the following: 
Protocol control information compression. 
User data compression. 

- Segmentation of compressed information into SN-DATA or SN-UNITDATA PDUs. 
The order of functions is vice versa in the reception flow: 

- Reassembly of SN-PDUs to SN-PDUs. 
User data decompression. 

Protocol control information decompression. 
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Figure 4: SNDCP model 
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The SNDCP layer expects the following services to be provided by the LLC layer. LLC layer functionality is defined in 

GSM 04.64 [6]: 

Acknowledged and unacknowledged data transfer. 

Point-to-point and point-to-multipoint data transfer. 

In-order delivery of SN-PDUs per SAPI (i.e. SN-PDUs using the same SAPI shall appear at the receiving end in 
the same order as transmitted). This is required only for acknowledged service. 

- QoS profile-based transfer of SN-PDUs. 
Support for variable length SN-PDUs. 

- Transfer of SNDCP XID parameters. 

The SNDCP layer expects the following services to be provided by the SM sublayer. SM sublayer functionality is 
defined in GSM 04.08 [5]: 

Activation and deactivation of PDP Contexts and informing the SNDCP layer when change in PDP context has 
happened. 

- Carrying out Inter SGSN Routing Area Update and informing the SNDCP layer in the SGSN when the N-PDUs 
shall be tunneled to the new SGSN. 

Notifying the SNDCP layer when there is need to change the QoS profile parameters of the PDP contexts. 



6 Protocol Functions 

6.1 Multiplexing of N-PDUs 

The NSAPI field shall be used for the identification of the specific PDP type and PDP address pair that is using the 
services provided by the SNDCP layer. The MS allocates NSAPIs dynamically at the PDP Context Activation. The 
NSAPI is delivered by the SM sub-layer to the SNDCP layer with the SNSM-ACTIVATE.indication primitive. The 
transmitting SNDCP entity shall insert the NSAPI value for each N-PDU. The peer SNDCP entity uses the NSAPI to 
identify the SNDCP user the N-PDU is targeted. Table 3 shows an example for the allocation of the NSAPIs. 

Table 3: Example of the NSAPI allocation 



PDP type 


Allocated NSAPI 


PDP address 


IP 


12 


133.12.75.111 


X.25 


13 


13254 



6.2 N-PDU buffering 



The N-PDUs are buffered in the SNDCP layer before they are compressed segmented and transmitted to the LLC layer. 
The reception of a SNSM-DEACTIVATE.indication triggers the deletion of the buffer for the related NSAPI. 

For acknowledged data transfer, an SNDCP entity shall buffer an N-PDU until successful transmission of all SN-PDUs 
carrying a segment of the N-PDU have been confirmed by the LLC layer. The confirmation is carried out using the LL- 
DATA.confirm or SNSM-WINDOW.indication primitives. At SGSN, for each LL-DATA.request sent to the LLC layer 
a LL-DATASENT.indication primitive is returned to SNDCP as soon as a LLC send sequence number has been 
assigned to the LLC PDU. This LLC send sequence number is included in the LL-DATASENT.indication primitive. At 
the SNDCP entities, the buffered N-PDUs which have been completely received as indicated by the acknowledgements 
in an LL-D ATA. confirm primitive are discarded. During the Inter-SGSN RA Update, the N-PDUs whose complete 
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reception by the MS has been confirmed in the SNSM-WINDOW.indication primitive are discarded, as defined in GSM 
09.60 [7] and GSM 03.60 [3 

For unacknowledged data transfer, the SNDCP shall delete an N-PDU immediately after it has been delivered to the 
LLC layer. 

6.3 Management of delivery sequence 

The SNDCP layer shall retain the delivery sequence of N-PDUs of each NSAPI between the peer entities. The delivery 
sequence of N-PDUs from different NSAPIs may alter according to the QoS requirements. 

6.4 Protocol Control Information Compression 

Protocol control information compression is an optional SNDCP feature. Only TCP/IP header compression has been 
specified in this specification. 

Negotiation of the supported algorithms and their parameters is carried out between MS and SGSN using the SNDCP 
XID parameters (see clause 8). 

6.4.1 Negotiation of multiple protocol control information compression 
types 

Each SNDCP entity that supports protocol control information compression shall be able to negotiate one or several 
protocol control information compression types with the SNDCP XID format shown in Figure 5. The negotiation shall 
be carried out using the XID parameter negotiation specified in subclause 6.7. The initiating entity defines a set of 
requested algorithms and their parameters. The set of algorithms and their parameters shall be transmitted to the peer 
entity. The peer entity responds with the set of negotiated algorithms and their parameters. The peer entity shall select 
the proposed values or other appropriate values for the negotiated algorithms. No more than 15 compression algorithms 
(excluding the no compression alternative) shall be selected by the peer entity. If the peer entity responds with an 
algorithm set including more than 15 algorithms and parameters, only the 15 first algorithms shall be taken into 
consideration. The rest of the negotiated algorithms are ignored without error notification. 



bit 


8 


7 


6 


5 4 3 2 1 


octet 1 


X 


X 


X 


Algorithm Type 


octet 2 


Applicable NSAPIs for SN-DATA 


octet 3 


Applicable NSAPIs for SN-DATA 


octet 4 


Applicable NSAPIs for SN-UNITDATA 


octet 5 


Applicable NSAPIs for SN-UNITDATA 


octet 6 


Length = n - 6 


octet 7 


High-order octet 






octet n 


Low-order octet 



Figure 5: Protocol control information compression field format for SNDCP XID negotiation 

Spare bit (X): 

Shall be set to 0. If SN-PDU is received with the Spare bit set to 1, the field shall be ignored without error 
notification. 

Table 4 show the list of protocol control information compression algorithms supported by the SNDCP layer. When new 
compression algorithms are needed for SNDCP, Table 4 shall be updated. 
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Table 4: List of protocol control information compression algorithms supported by SNDCP 



Compression algorithm 


Algorithm type (Range 0-31) 


RFC1144 
IP 





RFC 11 44 
Uncompressed TCP/IP 


1 


RFC1144 
Compressed TCP/IP 


2 


- 


Other values Reserved 



The values for the PCOMP shall be defined dynamically, based on the negotiation of the XID parameters for protocol 
control information compression. PCOMP value is reserved for no compression. Other 15 values (1-15) are derived 
from the set of negotiated data compression algorithms. If TCP/IP header compression shall be used for at least one 
NSAPI, PCOMP values must be allocated for each of the algorithm types 0, 1 and 2 in table 4. The NSAPI(s) that wish 
to use TCP/IP header compression must also be indicated for each of the algorithm types in the XID negotiation. 

When a compression algorithm is not included in the XID 'Protocol Control Information Compressions' parameter field 
(Section 8), that algorithm is not applicable for the NSAPI(s) involved in the XID-negotiation; i.e. the default value for 
the 'Protocol Control Information Compressions' parameter is no compression.. 

6.4.1.1 Assignment of PCOMP values 

The assignment of the PCOMP values follows the following general rule: 

PCOMP value is reserved permanently for no compression. 

PCOMP value 1 shall be assigned for the first algorithm on the set of the negotiated algorithms. PCOMP value 2 
shall be assigned for the second algorithm on the set of the negotiated algorithms. This rule continues until the 
PCOMP value has been assigned for all the negotiated algorithms. However, if parameter values have been 
negotiated for the same algorithm in more than one field inside the XID block (applicable for different NSAPIs), 
the same PCOMP value shall be assigned to all instances of the same algorithm. The compression entities will be 
identifiable by a combination of NSAPI and PCOMP values in the SN-(UNIT)DATA frame header. If XID 
parameters are renegotiated during a connection, the PCOMP value of an algorithm used both before and after 
the renegotiation shall not be changed. 

While transferring data, the compression algorithm type used for the SN-PDU is conveyed in the PCOMP field of the 
SNDCP header. Any successfully negotiated algorithm may be used for compression of N-PDU. 

In case the compression parameters are renegotiated during an existing connection, the configuration is not affected if 
the parameter values do not change. However, if the parameters change, the compression entities and the LLC link are 
reset. A renegotiation of the compression parameters is performed using LL-XID primitives if the parameters have not 
been changed in the initiating XID block. If the parameters have been changed in the initiating block, LL-ESTABLISH 
primitives are used. If the parameters have been modified only in the responding XID block, LLC link and compression 
entity reset is initialised using LL-ESTABLISH primitives following the reception of the responding XID block. 

When an LLC link used for a particular compression entity is reset or released, the compression entity is also reset. 
The compression entity reset is initialised by reception of LLC-ESTABLISH. indication, LLC- 
ESTABLISH.confirm, LL-RELEASE.indication, or LL-RELEASE.confirm primitives. 



6.4.2 TCP/IP header compression 



The protocol control information compression method is specific for each network layer protocol type. TCP/IP (IPv4) 
header compression is specified in RFC 1 144 [9]. 

The underlying service shall be able to distinguish three types of SN-PDUs (i.e., IP, Uncompressed TCP/IP, and 
Compressed TCP/IP), as defined in RFC 1 144 [9]. Those three SN-PDU types are defined as three different algorithm 
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types in Table 5. When the TCP/IP header compression is negotiated at the SNDCP XID exchange, PCOMP values for 
the three algorithm types shown in Table 4 shall be negotiated. Also one compression parameter — The Number of 
State Slots — must be negotiated between the compression entities. 

Table 5: RFC 1144 TCP/IP header compression parameters 



Algorithm 
Name 


Algorithm 
Type 


Length 


Format 


Range 


Sense of 
Negotiation 


Default Value 


RFC 1144 

Compressed 

TCP/IP 


2 


1 


SoSoSoSoSoSo 
SoSo 


0-254 


down 


16 



So The Number of State Slots 

The number of memory locations for saved packet headers. [9] 

If the So parameter is not included in the field negotiating the use of RFC 1 144 Compressed TCP/IP in either direction 
of negotiation, the default value for the parameter will apply. If So is not included in the initiating XID block, the 
responding end reads this as a default value offer and may negotiate another value according to the rules of negotiation. 



6.5 Data compression 



Data compression is an optional SNDCP feature. Data compression applies to both SN-DATA and SN-UNITDATA 
primitives. 

Figure 6 shows an example how the SNDCP functions may be used. Several NSAPIs may use a common data 
compression entity, i.e., the same compression algorithm and the same dictionary. Separate data compression entities 
shall be used for acknowledged (SN-DATA) and unacknowledged (SN-UNITDATA) data transfer. Several NSAPIs 
may be associated with one SAPI, i.e., they may use the same QoS profile. 



SNDCP users 



NSAPI 




PDP 

or 
Relay 



PDP 

or 
Relay 



Protocol 
compr. 



Data 
compr. 



Data 
compr. 





C3> 



SNDCP layer 



Protocol 
compr. 



Protocol 
compr. 



Data 
compr. 





SARI (SoS>) (SoS>) (SoS3) (SoS>) 



LLC layer entity 



Figure 6: An example for the usage of NSAPIs, SNDCP functions, and SAPIs 
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6.5.1 Negotiation of multiple data compression types 

Each SNDCP entity that supports data compression shall be able to negotiate one or several data compression types with 
the SNDCP XID format shown in Figure 7. The negotiation shall be carried out using the XID parameter negotiation 
specified in subclause 6.7. The initiating entitydefines a set of requested algorithms and their parameters. The set of 
algorithms and their parameters shall be transmitted to the peer entity. The peer entity responds with the set of 
negotiated algorithms and their parameters. The peer entity shall select the proposed values or other appropriate values 
for the negotiated algorithms. No more than 15 compression algorithms (excluding the no compression alternative) shall 
be selected by the peer entity. If the peer entity responds with an algorithm set including more than 15 algorithms and 
parameters, only the 15 first algorithms shall be taken into consideration. The rest of the negotiated algorithms are 
ignored without error notification. For each NSAPI one or more data compression are chosen.. This choice is also 
indicated in the SNDCP XID. Only NSAPIs that are using the same SAPI may use the same data compression entity. If 
more than one compression entity is chosen for an NSAPI, these entities must use different data compression algorithms. 
However, only one data compression entity is used for one N-PDU; i.e. the used data compression entity may be 
changed from N-PDU to N-PDU. 



bit 


8 


7 


6 


5 4 3 2 1 


octet 1 


X 


X 


X 


Algorithm Type 


octet 2 


Applicable NSAPIs for SN-DATA 


octet 3 


Applicable NSAPIs for SN-DATA 


octet 4 


Applicable NSAPIs for SN-UNITDATA 


octet 5 


Applicable NSAPIs for SN-UNITDATA 


octet 6 


Ixngth = n - 6 


octet 7 


High-order octet 






octet n 


Low-order octet 



Figure 7: Data compression field format for SNDCP XID negotiation 



Spare bit (X): 



Shall be set to 0. If SN-PDU is received with the Spare bit set to 1, the field shall be ignored without error 
notification. 

Table 6 shows the list of data compression algorithms supported by the SNDCP layer. When new compression 
algorithms are needed for SNDCP, Table 6 shall be updated. 

Table6: List of data compression algorithms supported by SNDCP 



Data compression 
algorithm 


Algorithm type 
(Range 0-31) 


V.42 bis 





- 


Other values Reserved 



When a compression algorithm is not included in the XID 'Data Compressions' parameter field (Section 8), that 
algorithm is not applicable for the NSAPI(s) involved in the XID-negotiation; i.e. the default value for the 'Data 
Compressions' parameter is no compression.. 

6.5.1.1 Assignment of DCOMP values 

The assignment of the DCOMP values follows the following general rule: 

DCOMP value is reserved permanently for no compression. 

DCOMP value 1 shall be assigned for the first algorithm on the set of the negotiated algorithms. DCOMP value 2 
shall be assigned for the second algorithm on the set of the negotiated algorithms. This rule continues until the 



ETSI 



GSM 04.65 version 6.1.0 Release 1997 



23 



TS 101 297 V6.1.0 (1998-07) 



DCOMP value has been assigned for all the negotiated algorithms. However, if parameter values have been 
negotiated for the same algorithm in more than one field inside the XID block (applicable for different NSAPIs), 
the same DCOMP value shall be assigned to all instances of the same algorithm. The compression entities will be 
identifiable by a combination of NS API and DCOMP values in the SN-(UNIT)DATA frame header. If XID 
parameters are renegotiated during a connection, the DCOMP value of an algorithm used both before and after 
the renegotiation shall not be changed. 

While transferring data, the compression algorithm type used for the SN-PDU is conveyed in the DCOMP field of the 
SNDCP header. Any successfully negotiated algorithm may be used for compression of N-PDU. 

In case the compression parameters are renegotiated during an existing connection and only the applicable NSAPI(s) 
change, the configuration of the compression entity is not affected. However, if the parameters change, the compression 
entities and the LLC link are reset. A renegotiation of compression parameters is performed using LL-XID primitives if 
the parameters have not been changed in the initiating XID block. If the parameters have been changed in the initiating 
block, LL-ESTABLISH primitives are used. If the parameters have been modified only in the responding XID block, 
LLC link and compression entity reset is initialised using LL-ESTABLISH primitives following the reception of the 
responding XID block. 

When an LLC link used for a particular compression entity is reset or released, the compression entity is also reset. The 
compression entity reset is initialised by reception of LLC-ESTABLISH.indication, LLC-ESTABLISH. confirm, LL- 
RELEASE. indication, or LL-RELEASE.confirm primitives. 

6.5.2 Management of V.42 bis data compression 

V.42 bis data compression may be used with SN-DATA primitives and SN-UNITDATA primitives. 

ITU-T V.42 bis is specified in [8]. The use of data compression function and associated parameters shall be negotiated 
at initial connection establishment. The parameters PO, PI, and P2 shall be transferred between the SNDCP layers at the 
MS and the SGSN. 

Table?: V.42 bis data compression parameters 



Algorithm 
Name 


Algorithm 
Type 


Length 


Format 


Range 


Sense of 
negotiation 


Default value 


V.42bis 





4 


Po Po 


0-3 


down 

(each direction 
separately) 


3 








Pi Pi Pi Pi Pi Pi Pi Pi 
Pi Pi Pi Pi Pi Pi Pi Pi 


512-65535 


down 


2048 


P2P2P2P2P2P2P2P2 


6-250 


down 


20 



Po V.42bis compression request 

Two bits are used to indicate the usage of compression, one bit for each direction. 

00 compress neither direction 

01 compress MS-to-SGSN direction only 

10 compress SGSN-to-MS direction only 

1 1 compress both directions 

Pi V.42bis number of codewords 
Maximum number of codewords in the compressor dictionary. 
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P2 V.42bis maximum string length 

Maximum number of characters in an uncompressed data string that is accepted to be encoded. 

If the Po, Pi, and P2 parameters are not included in the field negotiating the use of V.42bis in either direction of 
negotiation, the default values for the parameters will apply. If the parameters are not included in the initiating XID 
block, the responding end reads this as an offer for default values and may negotiate other set of values according to the 
rules of negotiation. 

SNDCP entity shall flush the compression dictionary after each N-PDU. 

When V.42 bis is used with SN-UNITDATA primitives the compression shall be terminated and the dictionary reset for 
each N-PDU, and the LLC protocol shall operate in the protected mode of operation. 

When V.42 bis is used with SN-DATA primitives and an error is detected by the decoder, the SNDCP entity shall use 
LL-ESTABLISH.request primitive to reset the logical link. 



6.6 Segmentation and reassembly 



Any (possibly compressed) N-PDU + SNDCP header shall be segmented by SNDCP if it is longer than N201 (see GSM 
04.64 [6]). In the segmentation, the SN-PDU is divided into multiple SN-PDUs. The M bit of the last SN-PDU is set to 
while the M bit of the other segments is set to 1 . The receiving SNDCP entity shall reassemble the segments back to 
the original N-PDU format. The segmentation and reassembly procedures are different for acknowledged and 
unacknowledged mode of operation. 

The PCOMP and DCOMP parameters shall only be included in the first segment. 

6.6.1 Segmentation in acknowledged mode 

The transmitting SNDCP entity shall segment an N-PDU into an ordered sequence of one or more SN-PDUs. The More 
bit (M) is used to identify the last segment. This procedure is illustrated in figure 4. 

6.6.2 Segmentation in unacknowledged mode 

The More bit is used to indicate N-PDU boundaries in the same way as specified for the acknowledged transmission 
mode. See figure 4 for illustration. 

The Segment offset indicates the offset from the beginning of the N-PDU in multiples of 128 octets. Four bits are used 
for the offset. 

The received segments belonging to the same N-PDU shall be buffered. If a timer (implementation dependent) elapses 
before all segments are received, the N-PDU shall be ignored. 

N-PDU number for PTP shall be inserted by the SNDCP entity. The N-PDU numbering starts from 0. For each of the 
following N-PDUs, the N-PDU number shall be increased by one. Modulo 524287 operation is applied. N-PDUs are 
numbered per NSAPI. Numbering cycles are reset at PDP context activation. 
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6.7 XID parameter negotiation 



Negotiation of XID parameters between peer SNDCP entities may be carried out to ensure optimal information transfer. 
The parameters are called SNDCP exchange identity (XID) parameters. SNDCP XID parameter negotiation may be 
started by the SNDCP entity at the MS or at the SGSN. The XID negotiation is a one-step procedure; i.e. the initiating 
end proposes parameter values, and the responding end either accepts these or offers different values in their place 
according to the XID negotiation rules described in this document; the rules limit the range of parameter values as well 
as the sense of negotiation. The initiating end accepts (or rejects) the values in the response; this concludes the 
negotiation. The block format for the SNDCP XID parameter negotiation is shown in figure 8. All parameters do not 
have to be included in the XID block, only parameters that are negotiated. Also it shall be possible to negotiate 
parameters for more than one NSAPI in one XID block since more than one NSAPI can use the same SAPI. At XID 
negotiation, all NSAPI(s) using the algorithm in questionshall be mentioned. At XID renegotiation, if additional 
applicable NSAPI(s) is/are indicated, these NSAPI(s) are added to an existing or to a new functional entity (e.g. a 
compression entity). At XID renegotiation, the NSAPI(s) which are not indicated anymore, are intepreted as having 
released the functional entity (e.g. a compression entity). If it is required that an NSAPI does not share a functional 
entity (e.g. a compression entity) with other NSAPI(s), only this NSAPI' s flag is set in the 'Applicable NSAPIs for SN- 
(UNIT)DATA' field. If there are no vacant entities at the responding SNDCP, no flag is set in the responding field, and 
the negotiation fails for the parameter in question. Data traffic through the NSAPI shall, however, continue if the failure 
does not make the connection inoperable. If flags for more than one NSAPI is set in the 'Applicable NSAPIs for SN- 
(UNIT)DATA' fields the same functional entity will be shared by all the indicated NSAPIs. The responding SNDCP 
may reject one or more NSAPIs, whose flags were set in the initiating message, by not setting the relevant flags in the 
answer. If parameters for a connection are renegotiated during an existing connection (e.g. because another NSAPI will 
share the functional entity) the effects depend on the parameter in question and are discussed in the corresponding 
sections of this document. One or several fields may be included into XID block while the negotiation between peer 
entities is carried out. In figure 8 the XID block is described. For each negotiated parameter, except version number, a 
bitmap is included that indicates which NSAPIs want to use this parameter. The bitmap is 2 octets. 

When the negotiation of SNDCP XID parameters has not been carried out prior to data transfer, default values shall be 
used; however, for parameter types 1 and 2, refer to sections 6.5.1/6.5.2 and 6.4.1/6.4.2, respectively. 
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Bit 


8 7 6 5 4 3 2 1 


Octet 1 


Parameter type=0 


Octet 2 


Version number 


Octet 3 


Parameter type=1 


Octet 4 


Length=n-4 


Octet 5 


XXX Algorithm type 


Octet 6 


Applicable NSAPIs for SN-DATA 


Octet 7 


Applicable NSAPIs for SN-DATA 


Octet 8 


Applicable NSAPIs for SN-UNITDATA 


Octet 9 


Applicable NSAPIs for SN-UNITDATA 


Octet 10 


Length=k-10 


Octet 1 1 


High-order octet 






Octet k 


Low-order octet 


Octet k+1 


XXX Algorithm type 


Octet k+2 


Applicable NSAPIs for SN-DATA 


Octet k+3 


Applicable NSAPIs for SN-DATA 


Octet k+4 


Applicable NSAPIs for SN-UNITDATA 


Octet k+5 


Applicable NSAPIs for SN-UNITDATA 


Octet k+6 


Length=m-(k-H6) 


Octet k+7 


High-order octet 






Octet m 


Low-order octet 






Octet n 


Low-order octet 


Octet n+1 


Parameter type=2 


Octet n+2 


Length=r-(n+2) 


Octet n+3 


XXX Algorithm type 


Octet n+4 


Applicable NSAPIs for SN-DATA 


Octet n+5 


Applicable NSAPIs for SN-DATA 


Octet n+6 


Applicable NSAPIs for SN-UNITDATA 


Octet n+7 


Applicable NSAPIs for SN-UNITDATA 


Octet n+8 


Length=p-(n-i-8) 


Octet n+9 


High-order octet 






Octet p 


Low-order octet 


Octet p+1 


XXX Algorithm type 


Octet p+2 


Applicable NSAPIs for SN-DATA 


Octet p+3 


Applicable NSAPIs for SN-DATA 


Octet p+4 


Applicable NSAPIs for SN-UNITDATA 


Octet p+5 


Applicable NSAPIs for SN-UNITDATA 


Octet p+6 


Length=q-(p-H6) 


Octet p+7 


High-order octet 






Octet q 


Low-order octet 






Octet r 


Low-order octet 



Figure 8: Example of SNDCP XID block format 
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The SNDCP user uses SN-XID. request to initiate the negotiation of the XID parameters. The SNDCP entity sends the 
proposed SNDCP XID parameters to the LLC SAP with the LL-XID .request or LL-ESTABLISH.request. The LLC 
SAP shall issue an XID command containing the SNDCP XID parameters (see GSM 04.64). The peer LLC SAP shall, 
upon receipt of the XID command, indicate the SNDCP XID parameters to SNDCP entity using LL-XID. indication or 
LL-ESTABLISH. indication. The peer SNDCP entity shall select appropriate values for the proposed parameters or 
negotiate the appropriate values with the SNDCP user entity with the SN-XID.indication and SN-XID.response 
primitives. When the appropriate parameter values are known by the peer SNDCP entity, it shall use the LL- 
XID .response or LL-ESTABLISH.response primitive to continue negotiation. Upon reception of the response, the LLC 
SAP shall send the received parameters to the SNDCP entity using the LL-XID. confirm or LL-ESTABLISH.confirm 
primitive. The SNDCP entity delivers the negotiated parameters to the SNDCP user. This is illustrated in Figure 9. The 
originator of the negotiation shall apply the new parameter values after it has received the 'confirm' primitive. The 
responding end of the negotiation shall apply the new parameter values after it has sent the replying 'response' primitive. 
If the format of the XID block is invalid or if the parameter values violate the sense of negotiation rules, SNDCP rejects 
the block; following this the initiator reinitiates the negotiation. If the XID block contains a parameter that is not 
recognised, the parameter is not responded to. If the initiating XID block contains recognisable parameters with invalid 
values, the responding end replies using valid values within the allowed value range. 

Negotiation of SNDCP version number is always between the peer SNDCP entities. The version number is not known 
by the SNDCP user. However, negotiation of the parameters for compression algorithms may be carried out between the 
SNDCP user entities. 

If default XID-parameter values will not be used, XID negotiation shall be carried out prior to data transfer. The 
SNDCP XID parameters are transferred using either LL-XID or LL-ESTABLISH primitives; LL-ESTABLISH 
primitives are used only when acknowledged peer-to-peer LLC operation has to be established or re-established. 



Originator 



Receiver 



SNDCP user SNDCP 



LLC 



LLC 



SNDCP SNDCP user 



SN-XID. req 



LL-XID. req 



XID 



LL-XID. ind 



SN-XID.ind 




SN-XID.cnf 



LL-XID.cnf 



Figure 9: SNDCP XID negotiation procedure 



6.8 



Data transfer 



6.8.1 Acknowledged mode 



The SNDCP entity shall initiate acknowledged data transmission only if the PDP context for the NS API identified in the 
SN-D ATA. request has been activated and if acknowledged LLC operation has been established. Upon reception of the 
SN-DATA.request, the SNDCP entity shall perform the compression and segmentation functions, then forward the SN- 
PDU in LL-DATA.request to the LLC layer. The N-PDU shall be stored into a buffer in the SNDCP entity. 
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When the peer SNDCP entity receives the SN-PDU in the LL-DATA.indication primitive, the SNDCP entity extracts 
the N-PDU from the SN-PDU, reassembles and decompresses the information, and forwards it to the SNDCP user with 
the SN-DATA.indication. The correct SNDCP user is identified by the NSAPI field in the SN-PDU. 

The SNDCP entity that has originated the transmission shall wait until the transmission of the SN-PDU is confirmed by 
an LL-DATA.confirm. After the confirmation of the last SN-PDU carrying a segment of an N-PDU, the N-PDU may be 
deleted from buffer. 



Originator 



SNDCP user 



SNDCP 



SN-DATA.req 



LL-DATA.cnf 



LLC 



LL-DATA.req 



LL- 
DATASENT.ind 



LL-DATA.cnf 



Receiver 



LLC 



SNDCP 



LL-DATA.ind 



LL-DATA.res 



SNDCP user 



SN-DATA.ind 



NOTE: LL-DATASENT.ind is returned to tine SNDCP layer in tine originating side if 
Originator is a SGSN. 

Figure 10: SNDCP acknowledged data transfer 

6.8.2 Unacknowledged mode 

The SNDCP entity shall initiate unacknowledged data transmission only if the PDP context for the NSAPI identified in 
the SN-DATA.request has been activated. The SNDCP entity may initiate unacknowledged data transmission even if the 
acknowledged peer-to-peer operation is not established for that NSAPI. Upon reception of the SN-UNITD ATA. request, 
the SNDCP entity shall compress and segment the information, then forward the SN-PDU in LL-UNITDATA.request to 
the LLC layer. The N-PDU shall be deleted immediately after the data has been delivered to LLC layer. 

When the peer SNDCP entity receives the SN-PDU in the LL-UNITDATA.indication primitive, the SNDCP entity 
extracts the N-PDU from the SN-PDU, reassembles and decompresses the information, then forwards it to the SNDCP 
user with the SN-UNITDATA.indication. The correct SNDCP user is identified by the NSAPI field in the SN-PDU. 
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Figure 11 : SNDCP unacltnowledged data transfer 
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6.9 Possible combinations of SNDCP Protocol Functions and 
their connection to service access points 

The following combinations of SNDCP protocol functions are allowed: 
One or several NSAPIs may use one SAPI 

- Only one SAPI shall be used by one NSAPI 

One or several NSAPIs may use the same protocol control information compression entity 
One NSAPI may use zero, one, or several protocol control information compression entities 
One or several NSAPIs may use the same data compression entity 
One NSAPI may use zero, one, or several data compression entities 

- Separate data compression entities shall be used for SN-DATA and SN-UNITDATA PDUs 

Separate protocol control information compression entities shall be used for SN-DATA and SN-UNITDATA 
PDUs 

One data compression entity shall be connected to one SAPI. 

One protocol control information compression entity shall be connected to one SAPI. 

One or several protocol control information compression entities may be connected to the same data compression 
entity. 

One protocol control information compression entity shall be connected to zero, one, or several data compression 
entities 



Definition of SN-PDU 



7.1 



Format convention 



7.1.1 



Numbering convention 



The convention used in this specification is illustrated in figure 12. The bits are grouped into octets. The bits of an octet 
are shown horizontally and are numbered from 1 to 8. Multiple octets are shown vertically and are numbered from 

I toN. 



Bit 


8 


7 


6 


5 


4 


3 


2 


1 


Oct 1 




2 








N-1 


N 



















Figure 12: Format convention 
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7.1.2 Order of transmission 

SN-PDUs are transferred between the SNDCP layer and LLC layer in units of octets, in ascending numerical octet order 
(i.e., octet 1,2, ..., N-1, N). The order of bit transmission is specific to the underlying protocols used across the Um 
interface and the Gb interface. 

7.1.3 Field mapping convention 

When a field is contained within a single octet, the lowest bit number of the field represents the lowest order value. 
When a field spans more than one octet, the order of bit values within each octet progressively decreases as the octet 
number increases. In that part of the field contained in a given octet the lowest bit number represents the lowest order 
value. 

For example, a bit number can be identified as a couple (o, b) where o is the octet number and b is the relative bit 
number within the octet. Figure 13 illustrates a field that spans from bit (1, 3) to bit (2, 7). The high order bit of the field 
is mapped on bit (1, 3) and the low order bit is mapped on bit (2, 7). 



Bit 


8 


7 


6 


5 


4 


3 


2 


1 


1st octet 
of field 












2" 


2' 


2' 


2nd octet 
of field 


2' 


2° 















Figure 13: Field mapping convention 

Figure 14 illustrates an NSAPI field that spans from bit (1,8) to bit (2,1). NSAPI 15 is mapped to bit (1,8) and the other 
NSAPIs are mapped in decreasingly order until NSAPI that is mapped to bit (2,1). A bit set to means that the 
compression entity is not applicable to the corresponding NSAPI. A bit set to 1 means that the compression entity is 
applicable to the corresponding NSAPI. 
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Figure 14: NSAPI mapping convention 



7.2 



SN-PDU Formats 



Each SN-PDU shall contain an integral number of octets, and shall comprise a header part and a data part. An SN-PDU 
shall contain data from a single N-PDU only. Two different SN-PDU formats are defined. The SN-DATA PDU shall be 
used for acknowledged data transfer and SN-UNITDATA PDU for unacknowledged data transfer. 
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Data segment 
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Figure 15: SN-Data PDU format 
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Bit 


8 


7 


6 


5 


4 


3 


2 


1 


Oct 1 


X 


C 


T 


M 


NSAPI 


2 


DCOMP 


PCOMP 


3 


Segment offset 


N-PDU number 


4 


E 


N-PDU number (continued) 


5 


N-PDU number (extended) 




Data segment 


N 



















Figure 16: SN-Unitdata PDU format 

More bit (M): 

Last segment of N-PDU 

1 Not the last segment of N-PDU, more segments to follow 
SN-PDU Type (T): 

SN-DATAPDU 

1 SN-UNITDATA PDU 
Compression indicator (C): 

Compression fields are not included. 

The octet including DCOMP and PCOMP is not included in the SN-Data PDU or SN-Unitdata PDU format. 

1 Compression fields are included. 

The values of the DCOMP and PCOMP fields are apphcable. 

Spare bit (X): 

Shall be set to 0. If SN-PDU is received with the Spare bit set to 1, the field shall be ignored without error 
notification. 

NSAPI: 

Escape mechanism for future extensions 

1 Point-to-Multipoint Multicast (PTM-M) information 
2-4 Reserved for future use 

5-15 dynamically allocated NSAPI value (see subclause 6.1) 
SN-PDU with an unallocated NSAPI value shall be ignored by the receiving SNDCP entity without error notification. 
Data compression coding (DCOMP): 

no compression 

1-14 Points to the data compression identifier negotiated dynamically (see subclause 6.4) 

15 Reserved for future extensions 
SN-PDU with an unallocated DCOMP value shall be ignored by the receiving SNDCP entity without error notification. 
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Protocol control information compression coding (PCOMP): 

no compression 

1-14 Points to the protocol control information compression identifier negotiated dynamically (see subclause 6.3) 

15 Reserved for future extensions 
SN-PDU with an unallocated PCOMP value shall be ignored by the receiving SNDCP entity without error notification. 
Segment offset: 

0-15 Segment offset from the beginning of the N-PDU in units of 128 octets 
N-PDU number: 

0-2047 Range used if Extension bit is set to 

2048-524287 Range used if Extension bit is set to 1 

The higher range is used only when the N-PDU number is such that more than 1 1 bits are needed to present the number 
in binary format. SN-PDU with an N-PDU number that is out of range shall be ignored by the receiving SNDCP entity 
without error notification. 

In the N-PDU number field bit in position (3, 4) is the MSB and the bit in position (5, 1) is the LSB. The extension bit E 
in position (4, 8) is skipped, i.e. Bit 2'"^ in position (4, 7) is followed by bit 2'^ in position (3, 1). 

Extension bit for N-PDU number (E): 

Next octet is used for data 

1 Next octet is used for N-PDU number extension 

8 SNDCP XID parameters 

The SNDCP XID parameters are shown in Table 8: 

Table 8: SNDCP XID parameters 



Parameter name 


Parameter 
Type 


Length 


Format 


Range 


Default value 


Units 


Sense of 
negotiation 


SN-VER (SNDCP 
version number) 





1 


OOOObbbb 


0-15 





- 


down 


Data Compressions 


1 


variable 


see subclause 6.5.1 


Protocol Control 

Information 

Compressions 


2 


variable 


see subclause 6.4.1 



NOTE: The current version of SNDCP is 0. This is also the default value for the version number. It is assumed 
that the future versions are backward compatible with former ones. 
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Annex A (informative): 
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Based on the 04.62 v. 0.3.0. Specification number 
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13.02.1997 


0.2.0 


Changes from SMG3 GPRS Ad-hoc 20-22.01.1997: 

- SMG3 97G012: Buffering of N-PDUs in SNDC 

- SMG3 97G011: Maximum GPRS N-PDU Size 

- Ciphering for SN-UNITDATA primitive added 
Editorial modifications to clean the text 


25.02.1997 


0.3.0 


Change from SMG3 GPRS Ad-hoc 24-28.02.1997: 

- Ciphering moved from SNDCP layer to the LLC layer. 


27.04.1997 


0.4.0 


Changes from SMG3 GPRS Ad-hoc 21-25.04.1997: 

- SMG3 97G142: Adapting SN-Unitdata PDU format to 
PTM-M functions 

- SMG3 97G193: Negotiation of compression 
Editorial modifications (not marked with revision 
marks). 


28.05.1997 


0.4.1 


Converted to 1997 Format regime by ETSI 


03.06.1997 


1.0.0 


Approved by SMG3 plenary, Malmo, Sweden, May 1997 
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1.1.0 


Changes from GPRS drafting meeting, Oslo, 4-6.06.1997 

- Data compression added for unacknowledged transfer 

- Priority field removed 


16.08.1997 


proposed version 1 .2.0 


Major rewrite after GPRS drafting session, Stockholm, 
7-11.7.1997 

- All explanation texts removed and just specification 
text was kept. The protocols specified elsewhere are no 
more re-specified 

- PTM related issues removed 

- Scope rewritten 

- Some normative references added 

- Figures improved 

- Major improvements in service primitives 

- Modifications in service functions 

- Improvements in protocol functions 

- Improvements to SN-PDU formats 

- Definition of SNDCP XID parameters 

16.08. 1997, Rework to ahgn with latest versions of GSM 
04.07 and GSM 04.64. 
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- LL-RESET primitives removed 

- XID Negotiation and XID field formats improved 

- NSAPI, SNDCP functions, and SAPI figure improved 

- Fixed NSAPI value for escape mechanism and PTM-M 

- Compression indicator (C) added to SN-DATA and 
SN-UNITDATA PDU formats 

- Acknowledged and unacknowledged data transfers 
clarified with figures 

- Plenty of editorials 

- Additional improvements to the whole specification 

- Separate compression entities to be used for 
acknowledged and unacknowledged services 

- Alignment with current versions of GSM 04.64 and 
GPRS CR to 04.07 
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1.3.1 


Accepted version from SMG3 Plenary 23-25 September 
1997. Editorial correction: NSMM primitive names 
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